Description

This PR introduces additive, non-breaking API fields to support the Hybrid Cloud Environment creation redesign (3-step flow with explicit storage configuration), while preserving existing behavior for external API consumers.
It adds a new enum to represent the readiness state of storage configuration in a hybrid cloud environment and integrates it into the HybridCloudEnvironmentStatus struct. At the same time it introduces a new enum for providing a reason why a cluster can't be created (or shouldn't) for a CloudProviderRegion, this will help slowly rolling out the transition before we switch available to false. See the detailed explanation below.

The goal is to enable finer-grained cluster creation gating in Cloud UI without changing the current meaning of existing fields (especially available).

Background

We are moving from an implicit/default storage behavior to an explicit storage configuration requirement in the Cloud UI flow.
At the same time, we are backfilling existing in-use environments that currently rely on defaults.

We need to expose enough status detail so UI can safely block/allow cluster creation, but without introducing breaking changes for current Public API consumers.

Why This Approach

Boolean fields are difficult to evolve in public contracts (true/false/null quickly becomes insufficient).
Enums provide forward-compatible extensibility for new states (e.g. backfill in progress, invalid configuration, policy restrictions).

API Changes (Additive)

HybridCloudEnvironmentStatus.storage_configuration_readiness (enum)

• UNSPECIFIED
• READY
• NOT_READY
• INVALID

CloudProviderRegion.cluster_creation_blocking_reason (enum)

• UNSPECIFIED
• NONE
• HYBRID_ENV_NOT_READY
• STORAGE_CONFIGURATION_NOT_READY

Compatibility and Breaking-Change Considerations

• Schema compatibility: non-breaking (new optional/additive fields only).
• Behavior compatibility: preserved.
• available is intentionally not repurposed at this stage to avoid behavioral breakage for existing API consumers.

Rollout Plan

• Add and populate new enum fields (UNSPECIFIED default).
• Keep existing available logic unchanged.
• Use Cloud UI + Statsig gate to enforce new creation checks based on the new fields.
• Complete backfill for existing environments.
• Consider future deprecation/migration path if we later want to unify gating semantics for all consumers.

Risk Assessment

Low risk to existing integrations (additive API changes only).
Main risk is semantic confusion between availableand creation gating; mitigated via explicit cluster_creation_blocking_reason and docs.